Systems and methods for routing electronic transactions using network simulation and forecasting

ABSTRACT

Systems and methods are for routing electronic payment transactions to PIN-less networks using payment pseudo-networks and electronic transaction simulation. One method comprises: receiving transaction-related information from a merchant, the transaction-related information including a bank identification number (“BIN”), one or more available network IDs, one or more merchant categories, an issuer regulatory status, a transaction amount, and a preferred status; extracting routing criteria from the received transaction-related information; dynamically identifying one or more eligible networks based on extracted routing criteria; dynamically identifying one or more breakeven transaction amounts for each identified eligible network, each breakeven transaction amount defining a point at which two or more eligible networks have the same expenses for a given transaction amount; and routing signature debit transactions from the merchant to a least cost PIN-less network selected from the eligible networks based on identification of a desired breakeven transaction amount for the PIN-less network.

FIELD OF DISCLOSURE

The present disclosure relates generally to the field of routingelectronic payment transactions and, more particularly, to routingelectronic payment transactions using payment pseudo-networks andelectronic transaction simulation and forecasting.

BACKGROUND

In the world of payments, merchants, such as retailers and e-commercesites, may choose various acquiring institutions or banks (“acquirers”)to process payment transactions through the various payment networksused by consumers. The payment networks may include credit networks(e.g., Visa, Master Card, Discover, American Express, etc.) and/or debitnetworks (e.g., Star, Plus, Jeanie, Pulse, etc.). Consumer card issuersmay decide which groups and types of networks to accept, and merchantsmay further determine which processors and networks to routetransactions through.

Payment networks, in turn, may use a number of factors to determine theinterchange category and/or interchange rate for a given transaction.Some of these factors may be controlled or influenced by the merchant,the factors including but not limited to, the processing method (e.g.,card present and card-not-present), the Merchant Category Code (MCC),and transaction data. However, payment networks may also use factorsthat may be outside of the control of a merchant to determine theinterchange category and/or interchange rate for a given transaction.These factors, which a merchant may not be able to control or influenceinclude, but are not limited to, the card type (separate interchangecategories exist for credit and debit as well as corporate cards,prepaid cards, etc.), the card brand (Visa, MasterCard, etc.), and/orthe card owner (whether a credit or debit card is issued by a smallcredit union, regional bank or large National bank).

If a merchant has a large volume of transactions, then the savings frompaying the lowest transaction fees could easily add up to hundreds ofthousands of dollars per month. The ability to route transactions leastcost is further complicated by cases where a merchant has multiplelocations and/or multiple business lines per location in the case ofmulti-format retailer, such as a “big box store” (ex: photographysection, salon section, vision section, electronics section, apparelsection, etc., wherein each section may have its own MCC).

Furthermore, analyzing transaction costs and making routing decisionsmay be complicated by both (i) mandatory state and Federal regulatoryrules and (ii) voluntary agreements among issuers, networks, andprocessors, any of which may pertain to negotiated transactionvolume/amount thresholds, negotiated markup rates, exemption fromregulations, and preferences. As an example, under the “Durbinamendment” of the Dodd-Frank financial reform legislation of 2010,financial institutions having over $10B in assets may be considered“regulated,” whereas financial institutions having less than $10B inassets may be “exempt.” Moreover, many Debit Networks (e.g. Star,Jeanie, etc.) create “preferred rates” that may be different from“standard rates,” and these rates may change from merchant to merchant,and/or from issuer to issuer. As a result, when compiling a “ratesheet,” it can be important to know which merchants or issuers arepreferred, and what the preferred rates are. Many networks also chargenot only based on “standard’ vs. “preferred,” but also regulated vs.exempt, and based on card type (prepaid, business, etc.) and transactionvolumes/amounts over time.

Thus, while a static table of networks or issuers might provide someinitial insights into costs, the real costs may depend on regulatorystatus and/or whether certain regulatory or contractual thresholds(maximums or minimums) have been reached in some given time period.Since actual costs or rates may depend on total numbers of transactions,it can be difficult to predict the real costs and/or the ideal routingfor any given transaction.

Thus, there is a desire for a system and method for allowing merchantsto automatically find the most desired networks through which to routeelectronic payment transactions, on a dynamic and granular level.

SUMMARY

According to certain aspects of the present disclosure, systems andmethods are disclosed for routing electronic payment transactions toPIN-less networks using payment pseudo-networks and electronictransaction simulation.

In one embodiment, a computer-implemented method is disclosed forrouting electronic payment transactions to PIN-less networks usingpayment pseudo-networks and electronic transaction simulation, themethod comprising: receiving transaction-related information from amerchant, the transaction-related information including a bankidentification number (“BIN”), one or more available payment networkIDs, one or more merchant categories, an issuer regulatory status, atransaction amount, and a preferred status; extracting routing criteriafrom the received transaction-related information; dynamicallyidentifying one or more eligible payment networks based on extractedtransaction routing criteria; dynamically identifying one or morebreakeven transaction amounts for each identified eligible network, eachbreakeven transaction amount defining a point at which two or moreeligible networks have the same expenses for a given transaction amount;and routing signature debit transactions from the merchant to a leastcost PIN-less network selected from the eligible networks based onidentification of a desired breakeven transaction amount for thePIN-less debit network.

In accordance with another embodiment, a system is disclosed for routingelectronic payment transactions to PIN-less networks using paymentpseudo-networks and electronic transaction simulation, the systemcomprising: a data storage device storing instructions for routingelectronic payment transactions to PIN-less networks using paymentpseudo-networks and electronic transaction simulation in an electronicstorage medium; and a processor configured to execute the instructionsto perform a method including: receiving transaction-related informationfrom a merchant, the transaction-related information including a bankidentification number (“BIN”), one or more available payment networkIDs, one or more merchant categories, an issuer regulatory status, atransaction amount, and a preferred status; extracting routing criteriafrom the received transaction-related information; dynamicallyidentifying one or more eligible payment networks based on extractedtransaction routing criteria; dynamically identifying one or morebreakeven transaction amounts for each identified eligible network, eachbreakeven transaction amount defining a point at which two or moreeligible networks have the same expenses for a given transaction amount;and routing signature debit transactions from the merchant to a leastcost PIN-less network selected from the eligible networks based onidentification of a desired breakeven transaction amount for thePIN-less debit network.

In accordance with another embodiment, a non-transitory machine-readablemedium storing instructions that, when executed by the a computingsystem, causes the computing system to perform a method for routingelectronic payment transactions to PIN-less networks using paymentpseudo-networks and electronic transaction simulation, the methodincluding: receiving transaction-related information from a merchant,the transaction-related information including a bank identificationnumber (“BIN”), one or more available payment network IDs, one or moremerchant categories, an issuer regulatory status, a transaction amount,and a preferred status; extracting routing criteria from the receivedtransaction-related information; dynamically identifying one or moreeligible payment networks based on extracted transaction routingcriteria; dynamically identifying one or more breakeven transactionamounts for each identified eligible network, each breakeven transactionamount defining a point at which two or more eligible networks have thesame expenses for a given transaction amount; and routing signaturedebit transactions from the merchant to a least cost PIN-less networkselected from the eligible networks based on identification of a desiredbreakeven transaction amount for the PIN-less debit network.

Additional objects and advantages of the disclosed embodiments will beset forth in part in the description that follows, and in part will beapparent from the description, or may be learned by practice of thedisclosed embodiments. The objects and advantages on the disclosedembodiments will be realized and attained by means of the elements andcombinations particularly pointed out in the appended claims.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive of the detailed embodiments, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a block diagram of an example environment and systems forrouting electronic payment transactions, in accordance with non-limitingembodiments.

FIG. 2A depicts a flow diagram of an exemplary method executed by atransaction routing server for routing electronic payment transactionsto PIN-less debit networks based on dynamic routing, in accordance withnon-limiting embodiments.

FIG. 2B depicts a flow diagram of an exemplary method executed by atransaction routing server for routing electronic payment transactionsusing payment pseudo-networks and electronic transaction simulation andforecasting, in accordance with non-limiting embodiments.

FIG. 3 depicts a plurality of modules and/or sub-systems of thetransaction routing server of FIG. 1, for routing electronic paymenttransactions to PIN-less debit networks and dynamically routingelectronic payment transactions using payment pseudo-networks andelectronic transaction simulation, in accordance with non-limitingembodiments.

FIG. 4A depicts a table of payment networks including createdpseudo-networks, in accordance with non-limiting embodiments.

FIG. 4B depicts a table of payment networks including createdpseudo-networks, sorted according to a simulated forecast of transactionvolume and rates, in accordance with non-limiting embodiments.

FIG. 5 depicts a screenshot of an exemplary user interface fordisplaying results of routing electronic payment transactions usingpayment pseudo-networks and electronic transaction simulation, andtransaction forecasting and iteration.

FIGS. 6A and 6B depict a report of an anonymized PIN-less debit systemincluding a report of value drivers of savings (FIG. 6A) and a report ofPIN-less network volume shift (FIG. 6B).

FIG. 7 is a screenshot of an exemplary graphical user interface (GUI)depicting routing and settlement results for an exemplary merchant.

FIG. 8 is a screenshot of an exemplary graphical user interface (GUI)depicting an exemplary issuer distribution of issuer, brand, and networkdetail, with selective user elements enabling sorting.

FIG. 9 is a screenshot of an exemplary graphical user interface (GUI)depicting an exemplary interface for reviewing and selecting analternate network eligibility.

DETAILED DESCRIPTION

Various non-limiting embodiments of the present disclosure will now bedescribed to provide an overall understanding of the principles of thestructure, function, and use of systems and methods disclosed herein forrouting electronic payment transactions using payment pseudo-networksand electronic transaction simulation.

As described above, in some cases, analyzing transaction costs andmaking routing decisions may be complicated by both (i) mandatoryregulatory rules and (ii) voluntary agreements among issuers, networks,and processors, any of which may pertain to transaction volume, markuprates, exemption from regulations, and preferences. As an example,financial institutions having over $10B in assets may be considered“regulated” under Durbin, whereas financial institutions having lessthan $10B in assets may be “exempt.” Moreover, many processors create“preferred rates” that may be different from “standard rates,” and theserates may change from merchant to merchant, and/or from issuer toissuer. As a result, when compiling a “rate sheet,” it can be importantto know which merchants or issuers are preferred, and what the preferredrates are. Many networks also change not only based on “standard’ vs.“preferred,” but also regulated vs. exempt, and based on card type(prepaid, business, etc.).

Thus, while a static table of networks or issuers might provide someinitial insights into costs, the real costs may depend on regulatorystatus and/or whether certain regulatory or contractual thresholds(maximums or minimums) have been reached in some given time period.Since actual costs or rates may depend on total numbers of transactions,it can be difficult to predict the real costs and/or the ideal routingfor any given transaction.

In view of the foregoing, the present disclosure describes embodimentsof a transaction routing server configured to generate “pseudo-networks”designed to be compared against networks when performing decisioningwithin a rate sheet of networks. “Pseudo-networks” may be artificialnetworks or modified versions of networks and configured to simulaterouting options within the payments environment. Specifically, thedisclosed embodiments involve generating pseudo-networks mimickingactual payment networks, and generating and updating routing tablesreflecting forecasted routing transaction costs to ensure desiredtransaction volumes are being achieved while minimizing acceptancecosts. The present disclosure also describes embodiments of atransaction routing server configured to perform simulation andforecasting of transaction routing. For example, the disclosedembodiments also involve simulating and forecasting transactions for thepurpose of comparing data against historical data, and forecastingvolume against negotiated thresholds.

Thus, the present disclosure is directed to a proprietary, comprehensivesolution for routing electronic payment transactions using paymentpseudo-networks and electronic transaction simulation. Moreover, theembodiments of the present disclosure enhance transaction routingintelligence and reduce the cost of acceptance.

As will be described in more detail below, the presently disclosedsystems and methods may route and optimize transactions according to oneor more of the following factors: merchant category code (MCC),regulatory (e.g., Durbin) qualification, transaction amount, fullacceptance cost (e.g., I/C, switch, other, etc.), identification ofstandard/premier issuer status, identification of business vs. prepaidcards, BIN/network identification, and/or interchangemonitoring/forecasting.

The disclosed embodiments are relevant to any type of credit and/ordebit transactions, including both PIN and PIN-less, and are designed toreduce expenses while also optimizing across various dimensionsaccording to various desires. As disclosed herein, the presenttechniques also include electronic displays for purposes of real-timereporting, monthly reporting, annual reporting, and the like, forreflecting to clients the savings resulting from the presently disclosedrouting techniques. The disclosed routing techniques also involve “PINprompting,” which reduces acceptance costs by steering consumers awayfrom signature transactions to PIN debit transactions, and seamlesslyrouting signature debit transactions to least-cost PIN-less debitnetworks.

As described above, the present disclosure is directed to both PIN andPIN-less transactions that reach a processor upon swiping, dipping, EMV,etc. initiation of a payment transaction. It should be appreciated thata payment processor may route each transaction to any of a number ofdifferent networks including Interlink (VISA), Maestro (MC), Pulse(Disc), Star (First Data), Accel, etc. In many cases, as a transactionis received, the processor may receive the primary account number(“PAN”), time/date stamp, amount, MCC, and determine the issuer byanalyzing the received PAN and determined which network or networks areenabled by the given issuer (e.g., a given issuer may have enabled,e.g., Interlink, Star, and Accel). According to the embodiments of thepresent disclosure, additional routing analysis and decisioning may beperformed to determine, in real-time, the actual cost of a giventransaction, based on one or more factors or criteria. For example, atransaction routing server consistent with the disclosed embodiments mayreceive transactions and extract routing criteria comprising, categorycode, ticket amount, and so on.

The cost of fees charged by acquirers and networks for paymenttransactions may impose significant costs on merchants, especially forlarge volumes of transactions. It may also be burdensome or otherwiseimpossible, to date, for a merchant, to sign up for and, at everypayment transaction, search for, the least cost acquirer, network,and/or pricing model, or be able to manage the communication oftransaction information between payment terminals, acquirer processors,and networks, especially when there are different messaging formats usedby the payment terminals or networks.

Thus, the embodiments of the present disclosure are also directed tomethods and systems to identify and achieve the lowest cost for eachpurchase transaction initiated by a merchant through the creation of amarketplace model. The marketplace model may include a computing system,which may include a “transaction routing server” that selects, fromamong a marketplace of networks, a network that provides the “leastcost” (e.g., lowest cost) acceptance or mark-up rate. Furthermore,various embodiments of the present disclosure describe systems andmethods for enabling the transaction routing server to communicate andnetwork efficiently between various payment terminals, and a pluralityof networks.

One or more examples of these non-limiting embodiments are illustratedin the selected examples disclosed and described in detail withreference made to the figures in the accompanying drawings. Those ofordinary skill in the art will understand that systems and methodsspecifically described herein and illustrated in the accompanyingdrawings are non-limiting embodiments. The features illustrated ordescribed in connection with one non-limiting embodiment may be combinedwith the features of other non-limiting embodiments. Such modificationsand variations are intended to be included within the scope of thepresent disclosure.

FIG. 1 depicts a block diagram of an example environment and systems forrouting electronic payment transactions to PIN-less debit networks anddynamically routing electronic payment transactions using paymentpseudo-networks and electronic transaction simulation. It should beappreciated that the embodiments of the present disclosure, includingFIG. 1, are also applicable to PIN debit and credit networks. At a highlevel, the transaction routing environment and systems (“system”) 100comprises: a payment vehicle 102 being used at a merchant 106 via aterminal 110A-C; a computing system (“transaction routing server” 116)that selects from among a marketplace of payment networks 122A-122C; aplurality of issuers 130A-130C; and a network 114 (e.g., the wired orwireless Internet, LAN, and/or PSTN) that may enable communicationbetween the various systems and entities. In some embodiments, certainrate qualification criteria 124A-124C, as determined by various paymentnetworks 122A-122C may be used to map an appropriate regulatory status132A-132C of an issuer 130A-130C to standard rates 126A-126C vs.preferred rates 128A-128C for a given issuer or merchant.

Still referring to FIG. 1, the payment vehicle 102 may be a tangibleobject (e.g., a credit card, debit card, gift card, etc.), an electronicdevice (e.g., in the case of ApplePay, Samsung Pay, Bitcoin, or thelike), and/or an intangible representation of a user's payment sourcethat may be used to initiate a payment transaction at a payment terminal110A-110C of a merchant 106 by delivering information regarding theconsumer's payment source (e.g., payment network 1 ID 104A, paymentnetwork 2 ID 104B, . . . payment network N ID 104C, etc.). It is alsocontemplated that for some merchants (e.g., e-commerce merchants), theremay not be a physical terminal. In such embodiments, a merchant's servermay serve as a terminal and the server may or may not have and/or send aterminal identifier. The payment vehicle may carry information of apayment network (e.g., Visa, MasterCard, Discover, American Express,JCB, etc., for credit networks, and/or Star, Plus, Jeanie, Cirrus, etc.,for debit networks) using a payment network identification 104A-104C.The payment network identification may include one or more of a paymentcard number, an issuer identification number, a primary account number(PAN), a bank card number, and/or a bank identifier code of a paymentsource account. A consumer may initiate a payment transaction at aterminal, for example, by swiping a card and/or otherwise facilitatingthe transmission of payment network identification (e.g.,electronically, verbally, etc.).

Still referring to FIG. 1, a merchant 106 may refer generally to anytype of retailer, service provider, or any other type of business thatis in networked communication with one or more issuers (e.g., Issuer 1130A, Issuer 2 130B, . . . Issuer N 130C, etc.) and may use the paymentprocessing services of the respective, acquirers, issuers, and/orunaffiliated processors/networks. Payment processing services mayinclude receiving and responding to authorization requests as well asfacilitating the settlement of funds associated with card-basedtransactions occurring at merchant 106. One or more terminals (e.g.,Terminal 1 110A, Terminal 2 110B, . . . Terminal N 110C, etc.) may bemapped to merchant 106. As is known in the art, each terminal 110A-110Cmay be generally unmodified or “stock” and simply facilitate thestandard transmission of transaction-related information to thecomputing system of an acquirer 130A-130C. In various embodiments of thepresent disclosure, the transaction routing server 116 may act or beperceived by the terminals as either an issuer or an acquirer processorcomputer system. Thus, each terminal 110A-C may facilitate thetransmission of transaction-related information to the transactionrouting server 116. The transaction-related information may comprise atransaction authorization request (“authorization request”), includingbut not limited to, a payment amount, a date, a time, a payment networkidentification (e.g., a primary account number and/or issueridentification number) as well as other types of identifying indicia(e.g., merchant identification 108, terminal identification 112A-C,etc.). The identifying indicia may vary based on the terminal 112A-C,the type of merchant 106, or the payment network being used at theterminal.

Still referring to FIG. 1, the network 114 may serve as a means forcommunicating information across the various systems and entities of theelectronic transaction routing system and environment. For example, insome embodiments, the network may facilitate the transmission of paymenttransaction information as well as identifying information of themerchant, terminal, and payment network used, to the transaction routingserver via the cloud, e.g., the Internet, or any type of wired orwireless wide area network. Network 114 may facilitate the periodic orcontinual updating of the transaction routing server 116 on paymentnetwork interchange rates from various computing systems, as well as themarkup rates for various acquirers from the computing systems of therespective acquirer institutions.

Still referring to FIG. 1, transaction routing server 116 may be acomputing system comprising at least one processor 118 and at least onedata storage device, e.g., database 120. In some embodiments, thetransaction routing server 116 may receive information from the merchant106 and/or terminals 110A-C, maintain a database 120 of storedinformation related to payment networks, issuers, regulatory status,rate qualification criteria, etc., periodically or continually updateits database 120, and transmit information back to merchant 106 and/orterminals 110A-C. Upon the initiation of a payment transaction at aterminal 110A-C, the transaction routing server 116 may receive varioustransaction related information, which may include, but is not limitedto, a BIN, identifications of available payment networks useable in thetransaction (“payment network IDs”), merchant categories, regulatorystatus, transaction amount, “preferred” or “premier” status, etc. Insome embodiments, the payment network identification may include apayment card number, whose first six digits may identify an issuerand/or bank institution that is associated with a payment network.

Still referring to FIG. 1, upon receiving the transaction-relatedinformation, the transaction routing server 116 may use the extractedpayment network identification to determine which payment networks atransaction may be use (e.g., payment network 1 122A, payment network 2122B, payment network 3 122C). Depending on the payment networksavailable, transaction routing server 116 may subsequently use thatpayment network's rate qualification criteria 124A-124C to determine thestandard rates 126A-126C vs. preferred rates 128A-128C for thetransaction. In some embodiments, transaction routing server 116 mayalso use the rate qualification criteria 124A-124C to determineinformation about the relevant issuer, such as a regulatory status132A-132C. In some embodiments, the regulatory status is determined bythe identity of the issuer (e.g., more or less than $10B in assets),whereas the standard vs. preferred rate is determined by the paymentnetwork.

Thus, transaction routing server 116 is configured to evaluate andselect, from one of many networks (e.g., Payment Network 1 122A, PaymentNetwork 2 122B, . . . Payment Network N 122C, etc.), a payment networkthat may yield the least cost markup rate for a given transaction. Insome embodiments, this selection may include comparing the markup rateswithin various pricing models for each of the acquirers, selecting thepricing model yielding the lowest markup rate, for each of theacquirers, identifying networks with the lowest rates for a givenstandard vs. preferred status, and a given regulatory exemption status,and then selecting the lowest interchange, “acceptance,” and/or “markup”rate among all of the networks.

Still referring to FIG. 1, in summary, once transaction routing server116 receives the transaction-related information from a terminal 110A-Cvia network 114, the transaction routing server 116 may retrieve, fromits database 120, the available rate information based on the ratequalification criteria of the payment networks available to be used inthe transaction. For example, if the transaction routing serveridentifies, based on the issuer ID and/or payment network ID provided inthe received transaction-related information that payment network 1 122Ais being utilized, transaction routing server 116 may retrieve, from itsdatabase 120, a list of eligible or available alternative paymentnetworks, their respective rate qualification criteria, their standardvs. preferred rates, and the issuer's regulatory status as either“exempt” or “regulated.” Subsequently, transaction routing server 116may determine, from one of many networks 122A-122C, the network thatprovides the overall best solution for the merchant, whether or not thatnetwork is actually the least costly for any given transaction. In someembodiments, the markup rates for the various networks and merchants maybe stored within database 120 of transaction routing server 116. Thedatabase 120 may be continually and/or periodically updated by computingsystems or servers representing the one or more issuers 130A-130C.

Still referring to FIG. 1, once transaction routing server 116determines a matrix of various markup rates across issuers and networks,transaction routing server 116 may determine the total rate that wouldbe incurred by the merchant for the transaction. Typically, the markuprate and/or the acceptance rate may be determined to be one or more of apercentage of the transaction amount, a flat charge, or a value amountadded to a percentage of the transaction amount. Once the acceptancerate and the least cost markup rate has been identified (e.g., from thedecision-making process depicted in FIGS. 2A and/or 2B), the rates maybe combined and/or may be sent along with the transaction-relatedinformation to the selected issuer or network with the least cost markuprate for further processing of the payment transaction. In someembodiments, the combined rates along with information related to oridentifying the selected network may be sent back to the paymentterminal of the merchant or a computing system of the merchant. In otherembodiments, after the combined rates along with transaction-relatedinformation has been sent to the selected network with the least costrate and the payment transaction has been further processed, theacquirer may send information (“transaction processing acknowledgmentinformation”) acknowledging the processing of the transaction back totransaction routing server 116. In such embodiments, transaction routingserver 116 may communicate the transaction processing acknowledgmentinformation to merchant 106 and/or payment terminal 110A-110C of themerchant.

Since the various payment terminals and servers associated with theplurality of merchants, acquirers, acquirer processors, and/or paymentnetworks, with which the marketplace transmits and/or receivesinformation, may use different messaging formats, it is envisioned thatin various embodiments of the present disclosure, the transactionrouting server 116 has the ability to translate between and/or supportplatforms of various messaging formats. For example, if a paymentterminal communicates transaction related information in JSON butacquirer 1 communicates information regarding the transaction in XML,the transaction routing server may receive the information regarding thetransaction from acquirer 1 in XML, translate the information to JSON,and deliver the information to the payment terminal in JSON. In someembodiments, the task of translating messages of various formats into aformat readable by the recipient device (e.g., terminal) may beperformed by processor 118 of transaction routing server 116.

FIG. 2A depicts a flow diagram of an exemplary method executed by atransaction routing server for routing electronic payment transactionsto PIN-less debit networks based on dynamic routing, in accordance withnon-limiting embodiments. Specifically, FIG. 2A depicts a method ofrouting a transaction over a PIN-debit network even if a PIN is notpresent, by leveraging a relationship with the issuer. Such techniquesmay be performed by adding “signature transactions” as separate networksin the sequencing of available networks and pseudo-networks. Forexample, a decision may be made on whether to send a given transactionthrough credit networks or through PIN debit rails.

Specifically, FIG. 2A depicts a method 200 for routing electronicpayment transactions to PIN-less networks using payment pseudo-networksand electronic transaction simulation. In one embodiment, method 200includes step 202, which may include receiving transaction-relatedinformation from a terminal. As illustrated in steps 204A-204F, thetransaction-related information may include an issuing or “issuer” bankidentification number (“BIN”) 204A, an identification of the availablepayment networks (“payment network IDs”) 204B, an identification of oneor more merchant categories 204C, an identification of a regulatorystatus of the issuer (issuing bank) 204D, the transaction amount chargedor to be charged 204E, and a preferred (or non-preferred) status 204Fassociated with the merchant affiliated with the transaction. In someembodiments, for example in transactions involving e-commerce, or anonline purchase, the transaction-related information need not include aterminal ID, e.g., where a physical terminal does not exist. The modesand/or forms of payment may include, but are not limited to, the type ofcard presented, the specific information contained in the transaction,how and when a payment transaction is processed, the industry of themerchant, whether additional services (e.g., address verificationservice (AVS)) are utilized, etc.

Step 206 may include extracting routing criteria from thetransaction-related information, including but not limited to the BIN204A, available payment network IDs 204B, merchant categories 204C,issuer regulatory status 204D, transaction amount 204E, and preferredstatus 204F. In some embodiments, a default or initial payment networkmay be identified from the first digit of the payment card number and/ora bank card number (e.g., Visa, MasterCard, Discover, American Express,JCB, etc., for credit networks, and/or Star, Plus, Genie, Cirrus, etc.,for debit networks).

Step 208 may include dynamically identifying eligible networks based onextracted transaction routing criteria. For example, step 208 mayinclude identifying eligible networks based on the identity of thecardholder's issuing bank and/or the identity and/or category of therelevant merchant corresponding to the transaction.

Step 210 may include dynamically identifying one or more breakeventransaction amounts for which each eligible network. In someembodiments, the breakeven point may define a point at which two or moreeligible networks have the same expenses for a given transaction amount.

Step 212 may include routing signature debit transactions to a leastcost PIN-less network. In some embodiments, signature debit transactionsmay be converted and routed to a least cost PIN-less network based onidentification of a desired breakeven transaction amount for thePIN-less debit network. For example, in one embodiment, step 212 mayinvolve routing signature debit transaction to PIN-less networks byleveraging a processor's relationship with a given network, or between amerchant and a network. Specifically, eligible transactions may bedetermined based on BIN and organization ID. For example, a particularBIN may be used for PIN-less network eligibility (accounting for largepercentages of total network volume), and organization ID (“Org ID”) maybe used to set thresholds for eligibility, such as a minimum of $X MM inannual sales and a maximum of 0.x % chargeback rate. Such chargebackrate thresholding may be used as a proxy for e-commerce eligibilityand/or risk profile analysis. In another embodiment, step 212 mayinvolve “PIN prompting,” which reduces acceptance costs by shiftingsignature transactions to PIN debit transactions, and seamlessly routingsignature debit transactions to least-cost PIN-less debit networks.

FIG. 2B depicts a flow diagram of an exemplary method executed by atransaction routing server for routing electronic payment transactionsusing payment pseudo-networks and electronic transaction simulation andforecasting, in accordance with non-limiting embodiments. Specifically,FIG. 2B depicts a method 220 for routing electronic payment transactionsusing payment pseudo-networks and electronic transaction simulation,forecasting, and iteration. In one embodiment, method 220 includes step222, which may include receiving transaction-related information from aterminal. As illustrated in steps 224A-224F, the transaction-relatedinformation may include an issuing or “issuer” bank identificationnumber (“BIN”) 224A, an identification of the available payment networks(“payment network IDs”) 224B, an identification of one or more merchantcategories 224C, an identification of a regulatory status of the issuer(issuing bank) 224D, the transaction amount charged or to be charged224E, and a preferred (or non-preferred) status 224F associated with themerchant affiliated with the transaction. In some embodiments, forexample in transactions involving e-commerce, or an online purchase, thetransaction-related information need not include a terminal ID, e.g.,where a physical terminal does not exist. The modes and/or forms ofpayment may include, but are not limited to, the type of card presented,the specific information contained in the transaction, how and when apayment transaction is processed, the industry of the merchant, whetheradditional services (e.g., address verification service (AVS)) areutilized, etc.

Step 226 may include extracting routing criteria from thetransaction-related information, including but not limited to the BIN224A, available payment network IDs 224B, merchant categories 224C,issuer regulatory status 224D, transaction amount 224E, and preferredstatus 224F. In some embodiments, a default or initial payment networkmay be identified from the first digit of the payment card number and/ora bank card number (e.g., Visa, MasterCard, Discover, American Express,JCB, etc., for credit networks, and/or Star, Plus, Genie, Cirrus, etc.,for debit networks).

Step 228 may include dynamically identifying eligible networks based onextracted transaction routing criteria. For example, step 208 mayinclude identifying eligible networks based on the identity of thecardholder's issuing bank and/or the identity and/or category of therelevant merchant corresponding to the transaction.

Step 230 may include generating pseudo-networks reflecting potentialalternative networks on which to route transaction. In some embodiments,pseudo-networks may be generated based on exempt vs. regulated statusand standard vs. preferred rates.

Step 232 may include generating one or more rate tables comprising asorting of eligible networks and generated pseudo-networks, andcorresponding routing and/or acceptance costs.

Step 234 may include identifying or receiving negotiated volumediscounts and/or regulatory exemption thresholds. For example, in somecases, merchants, processors, and/or networks may negotiate preferredrates and/or volume discounts for given transaction amounts ortransaction volumes. Thus, step 234 may comprise receiving informationabout negotiated volume discounts and/or regulatory exemptionthresholds.

Step 236 may include executing simulation and forecasting models basedon routing transactions across the one or more generated rate tables,constrained by the identified or received negotiated volume discountsand/or regulatory exemption thresholds. Step 238 may include identifyinga lowest opportunity-cost network or pseudo-network based on iterativesimulation of routing through the simulation and forecasting models.

For example, as will be discussed with respect to FIG. 3 below, one ormore of an iterative algorithm 308, simulation module 304, andforecasting module 306 may be configured to interact to accuratelyforecast the absolute dollar amount of routing, and minimize theopportunity cost of pulling transactions from one network and routingthem through another alternative network (e.g., a createdpseudo-network), so as to reach negotiated volume discounts, comply withregulatory rules, leverage preferred rates, and reach other importanttechnical and business goals. As an example, it may be the case that agiven merchant falls short of a negotiated volume rate by $1M. In such acase, it may be worth sending additional transactions to that network ina non-least-cost manner, just in order to get that volume discount.

FIG. 3 depicts a schematic diagram 300 of a plurality of modules and/orsub-systems of the transaction routing server 116 of FIG. 1, for routingelectronic payment transactions to PIN-less debit networks anddynamically routing electronic payment transactions using paymentpseudo-networks and electronic transaction simulation, in accordancewith non-limiting embodiments. Specifically, transaction routing server116 may include a pseudo-network creation module 302, a simulationmodule 304, a forecasting module 306, an iterative algorithm module 308,an opportunity cost calculator 310, and a parameter/threshold source 312for obtaining and disseminating, e.g., network options, issuerpreferences, volume rules/agreements, preferred rates, regulatory rules,etc. As shown in FIG. 3, at a high level, parameter/threshold source 312may obtain and disseminate parameters and thresholds, e.g., networkoptions, issuer preferences, volume rules/agreements, preferred rates,regulatory rules, etc. to the pseudo-network creation module 302 and theopportunity cost calculator 310. Results of simulation module 304 may befed into forecasting module 306 and iterative algorithm 308. Results offorecasting module 306 may be fed into iterative algorithm 308 and backinto simulation module 304.

In one embodiment, pseudo-network creation module 302 may be configuredto identify and generate new pseudo-networks to be included in ratetables and compared to existing payment networks in a dynamic routingalgorithm. In one embodiment, pseudo-network creation module 302 mayaccount for “standard” vs. “preferred” and card type, which enablescreation of a full and realistic table of the available rates. Moreover,pseudo-network creation module 302 may incorporate each of: signaturedebit networks, PIN debit networks, PIN-less debit networks, and creditnetworks (including chip-credit networks).

In one embodiment, simulation module 304 and forecasting module 306 mayinteract to simulate transaction routing over a period of time, such asover a day, week, month, quarter, year, and so on. Thus, simulationmodule 304 may be configured to implement and analyze the generatedtables of networks and pseudo-networks, and determine what total dollarvalue thresholds are achieved, and so on. Forecasting module 306 maythereby predict year-over-year growth, and predict other targets,thresholds, and metrics over time, using results of simulation module304.

Iterative algorithm 308 may be configured to receive inputs fromsimulation module 304 and forecasting module 306, as well as opportunitycost calculator 310 to determine which transaction to run in anon-least-cost manner that will ultimately achieve better long-termgoals. For example, one or more of iterative algorithm 308, simulationmodule 304, and forecasting module 306 may be configured to interact toaccurately forecast the absolute dollar amount of routing, and minimizethe opportunity cost of pulling transactions from one network androuting them through another alternative network (e.g., a createdpseudo-network), so as to reach negotiated volume discounts, comply withregulatory rules, leverage preferred rates, and reach other importanttechnical and business goals. As an example, it may be the case that agiven merchant falls short of a negotiated volume rate by $1M. In such acase, it may be worth sending additional transactions to that network ina non-least-cost manner, just in order to get that volume discount.Iterative algorithm 308, simulation module 304, and forecasting module306 may be configured to determine which merchant's transactions and/orwhich other network's transactions to route in order to achieve thedesired volume discount.

FIG. 4A depicts a table of payment networks including createdpseudo-networks, in accordance with non-limiting embodiments.

FIG. 4B depicts a table of payment networks including createdpseudo-networks, sorted according to a simulated forecast of transactionvolume and rates, in accordance with non-limiting embodiments.

FIG. 5 depicts a screenshot of an exemplary user interface fordisplaying results of routing electronic payment transactions usingpayment pseudo-networks and electronic transaction simulation, andtransaction forecasting and iteration.

FIGS. 6A and 6B depict a report of anonymized PIN-less debit systemincluding a report 602 of value drivers of savings (FIG. 6A) and areport 604 of PIN-less network volume shift (FIG. 6B). Specifically,FIG. 6A depicts a graphical report 602 of value drivers of savingsincluding, for example, regulatory (e.g., Durbin) qualification, 40+tables/MCC differentiation, card/product type identification, andoverall savings potential. FIG. 6B depicts a graphical report 604reflecting a representation of PIN-less network volume shift by percent(%) of PIN-less eligible transactions across various networks, including“no option” MasterCard/Visa (“MC/VS”), “least cost” MasterCard/Visa(“MC/VS”), Accel, Jeanie, Maestro, Star, and so on. The graphicalreports of FIGS. 6A and 6B reflect that, given at least one sampletransaction, as many as 99.94% of all signature debit transactions couldsatisfy current PIN-less eligibility requirements. Moreover, assumingleast cost priority 24.3% of eligible signature debit transactionsconverted PIN-less debit assuming certain PIN-less pricing.

FIG. 7 is a screenshot of an exemplary graphical user interface (GUI)depicting routing and settlement for an exemplary merchant, including adisplay of regulated vs. exempt issuer transactions and a distributionof transactions across eligible networks for the given transactioncriteria.

FIG. 8 is a screenshot of an exemplary graphical user interface (GUI)depicting an exemplary “issuer distribution,” e.g., of issuer, brand,and network detail, with selective user elements enabling sorting bycount, volume, state, issuer, network, etc. As shown in FIG. 8, in oneembodiment, it a circular graphical display may depict the relevantdistributions by both state and percentage within a given issuer. FIG. 8shows that, in this case, e.g., 50.5% of Bank of America MasterCardtransactions in Florida were routed to Star (where the PIN was entered),and that these transactions represented 1.86% of total pin transactionsin Florida. This type of interactive visualization may enable merchants(clients of the routing server system) to drill-down into debit volumeby state, regulated status, issuer, brand, PIN debit network, and so on.

FIG. 9 is a screenshot of an exemplary graphical user interface (GUI)depicting an exemplary interface for reviewing and selecting analternate network eligibility. Specifically, the visualization of FIG. 9enables a merchant (client of the routing server system) to betterunderstand a maximum volume opportunity for a given PIN debit network.As shown in FIG. 9, transactions are settled with the networks on thevertical axis, whereas the horizontal axis contains other eligiblenetworks for the transactions. In particular, as shown in FIG. 9, in oneembodiment, the disclosed interface may comprise different tabs forregulated vs. exempt issuers or networks. Each tab may comprise columnheaders indicating eligible networks of where transactions could besent, row headers indicating eligible networks where the transactionswere actually sent, and intersecting bubbles having sizes indicatingnumbers of transactions sent to one network that could have been sent toanother network, at a savings. Moreover, in one embodiment, mousingover, hovering over, or touch-tapping the vertical axis, the indicatedbubbles, or other locations, may expose raw and/or formatted data.

These and other embodiments of the systems and methods may be used aswould be recognized by those skilled in the art. The above descriptionsof various systems and methods are intended to illustrate specificexamples and describe certain ways of making and using the systemsdisclosed and described here. These descriptions are neither intended tobe nor should be taken as an exhaustive list of the possible ways inwhich these systems can be made and used. A number of modifications,including substitutions of systems between or among examples andvariations among combinations can be made. Those modifications andvariations should be apparent to those ordinarily skilled in this areaafter having read this disclosure.

It is intended that the specification and examples be considered asexemplary only, with a true scope and spirit of the invention beingindicated by the following claims.

1-20. (canceled)
 21. A computer-implemented method for routingelectronic payment transactions to debit networks using a simulationtransaction routing server, the method comprising: receiving, by atleast one processor of a transaction routing server, transaction-relatedinformation from a merchant via an electronic network; extracting, bythe least one processor of the transaction routing server, transactionrouting criteria from the transaction-related information; identifying,by at least one processor of a transaction routing server, a pluralityof eligible payment networks based on the transaction routing criteria;identifying, by at least one processor of a transaction routing server,a breakeven point at which two or more of the plurality of eligiblepayment networks have the same expenses for a given transaction amount;selecting, by at least one processor of a transaction routing server, aleast cost PIN-less debit network from the two or more of the pluralityof eligible payment networks based at least in part on the breakevenpoint; converting, by at least one processor of a transaction routingserver, the transaction-related information to a signature debittransaction in a message format readable by the least cost PIN-lessdebit network; and routing, by at least one processor of a transactionrouting server, the signature debit transactions in the second messageformat to the least cost PIN-less debit network.
 22. Thecomputer-implemented method of claim 21, wherein the transaction relatedinformation further includes one or more of: a primary account number;an issuer identification number; a payment card number; a mode ofpayment including a swiping of a card, keying in an identificationrelated to the payment network, a contactless mode of payment, or a modeof payment that utilizes a chip; and whether an address verificationsystem was utilized.
 23. The computer-implemented method of claim 21,further comprising: generating, by the at least one processor of thetransaction routing server, one or more pseudo-networks corresponding toone or more of the plurality of eligible payment networks, eachpseudo-network comprising a modification of a network to account for achange in regulatory exemption status or a change in preferred status.24. The computer-implemented method of claim 21, further comprising:dynamically sorting, by the at least one processor of the transactionrouting server, the identified plurality of eligible payment networksaccording to breakeven transaction amounts, absolute cost, availabilityof volume discount, and availability of preferred rates.
 25. Thecomputer-implemented method of claim 21, further comprising: receiving,by the at least one processor of the transaction routing server, anidentification of a regulatory threshold or negotiated volume threshold;generating, by the at least one processor of the transaction routingserver, one or more pseudo-networks corresponding to one or more of theplurality of eligible payment networks, each pseudo-network comprising amodification of a network to account for a change in regulatoryexemption status or a change in preferred status; dynamicallyidentifying, by the at least one processor of the transaction routingserver, one or more breakeven transaction amounts for each eligiblepayment network, the breakeven transaction amounts defining a point atwhich two or more of the plurality of eligible payment networks have thesame expenses for a given transaction amount; and dynamically sorting,by the at least one processor of the transaction routing server, theeligible payment networks and pseudo-networks to identify a least-costnetwork.
 26. The computer-implemented method of claim 21, furthercomprising: generating, by the at least one processor of the transactionrouting server, a display of routing and settlement across the pluralityof eligible payment networks, and user-configurable displays ofregulated vs. exempt issuers.
 27. The computer-implemented method ofclaim 21, further comprising: generating, by the at least one processorof the transaction routing server, a display of a first grouping of theplurality of eligible payment networks to which a set of transactionswere routed relative to a second grouping of the plurality of eligiblepayment networks to which the set of transactions could have beenrouted, for an overall cost savings to the merchant.
 28. Thecomputer-implemented method of claim 27, further comprising: generating,by the at least one processor of the transaction routing server, aplurality of user elements enabling the merchant to reveal a group oftransaction routing decisions according to issuer, regulatory exemptionstatus, and preference or preferred rate status.
 29. A system forrouting electronic payment transactions to PIN-less networks usingpayment pseudo-networks and electronic transaction simulation, thesystem comprising: a data storage device storing instructions forrouting electronic payment transactions to PIN-less networks usingpayment pseudo-networks and electronic transaction simulation in anelectronic storage medium; and at least one processor of a transactionrouting server, configured to execute the instructions to perform amethod including: receiving, by at least one processor of a transactionrouting server, transaction-related information from a merchant via anelectronic network; extracting, by the least one processor of thetransaction routing server, transaction routing criteria from thetransaction-related information; identifying, by at least one processorof a transaction routing server, a plurality of eligible paymentnetworks based on the transaction routing criteria; identifying, by atleast one processor of a transaction routing server, a breakeven pointat which two or more of the plurality of eligible payment networks havethe same expenses for a given transaction amount; selecting, by at leastone processor of a transaction routing server, a least cost PIN-lessdebit network from the two or more of the plurality of eligible paymentnetworks based at least in part on the breakeven point; converting, byat least one processor of a transaction routing server, thetransaction-related information to a signature debit transaction in amessage format readable by the least cost PIN-less debit network; androuting, by at least one processor of a transaction routing server, thesignature debit transactions in the second message format to the leastcost PIN-less debit network.
 30. The system of claim 29, wherein thetransaction related information further includes one or more of: aprimary account number; an issuer identification number; a payment cardnumber; a mode of payment including a swiping of a card, keying in anidentification related to the payment network, a contactless mode ofpayment, or a mode of payment that utilizes a chip; and whether anaddress verification system was utilized.
 31. The system of claim 29,wherein the system is further configured for: generating, by the atleast one processor of the transaction routing server, one or morepseudo-networks corresponding to one or more of the plurality ofeligible payment networks, each pseudo-network comprising a modificationof a network to account for a change in regulatory exemption status or achange in preferred status.
 32. The system of claim 29, wherein thesystem is further configured for: dynamically sorting, by the at leastone processor of the transaction routing server, the identifiedplurality of eligible payment networks according to breakeventransaction amounts, absolute cost, availability of volume discount, andavailability of preferred rates.
 33. The system of claim 29, wherein thesystem is further configured for: receiving, by the at least oneprocessor of the transaction routing server, an identification of aregulatory threshold or negotiated volume threshold; generating, by theat least one processor of the transaction routing server, one or morepseudo-networks corresponding to one or more of the plurality ofeligible payment networks, each pseudo-network comprising a modificationof a network to account for a change in regulatory exemption status or achange in preferred status; dynamically identifying, by the at least oneprocessor of the transaction routing server, one or more breakeventransaction amounts for each eligible network, the breakeven transactionamounts defining a point at which two or more of the plurality ofeligible payment networks have the same expenses for a given transactionamount; and dynamically sorting, by the at least one processor of thetransaction routing server, the eligible payment networks andpseudo-networks to identify a least-cost network.
 34. The system ofclaim 29, wherein the system is further configured for: generating, bythe at least one processor of the transaction routing server, a displayof routing and settlement across the plurality of eligible paymentnetworks, and user-configurable displays of regulated vs. exemptissuers.
 35. The system of claim 29, wherein the system is furtherconfigured for: generating, by the at least one processor of thetransaction routing server, a display of a first grouping of theplurality of eligible payment networks to which a set of transactionswere routed relative to a second grouping of the plurality of eligiblepayment networks to which the set of transactions could have beenrouted, for an overall cost savings to the merchant.
 36. The system ofclaim 35, wherein the system is further configured for: generating, bythe at least one processor of the transaction routing server, aplurality of user elements enabling the merchant to reveal a group oftransaction routing decisions according to issuer, regulatory exemptionstatus, and preference or preferred rate status.
 37. A non-transitorymachine-readable medium storing instructions that, when executed by thea computing system, causes the computing system to perform a method forrouting electronic payment transactions to PIN-less networks usingpayment pseudo-networks and electronic transaction simulation, themethod including: receiving, by at least one processor of a transactionrouting server, transaction-related information from a merchant via anelectronic network; extracting, by the least one processor of thetransaction routing server, transaction routing criteria from thetransaction-related information; identifying, by at least one processorof a transaction routing server, a plurality of eligible paymentnetworks based on the transaction routing criteria; identifying, by atleast one processor of a transaction routing server, a breakeven pointat which two or more of the plurality of eligible payment networks havethe same expenses for a given transaction amount; selecting, by at leastone processor of a transaction routing server, a least cost PIN-lessdebit network from the two or more of the plurality of eligible paymentnetworks based at least in part on the breakeven point; converting, byat least one processor of a transaction routing server, thetransaction-related information to a signature debit transaction in amessage format readable by the least cost PIN-less debit network; androuting, by at least one processor of a transaction routing server, thesignature debit transactions in the second message format to the leastcost PIN-less debit network.
 38. The non-transitory machine-readablemedium of claim 37, the method further comprising: generating, by the atleast one processor of the transaction routing server, one or morepseudo-networks corresponding to one or more of the plurality ofeligible payment networks, each pseudo-network comprising a modificationof a network to account for a change in regulatory exemption status or achange in preferred status.
 39. The non-transitory machine-readablemedium of claim 37, the method further comprising: dynamically sorting,by the at least one processor of the transaction routing server, theidentified plurality of eligible networks according to breakeventransaction amount, absolute cost, availability of volume discount, andavailability of preferred rates.
 40. The non-transitory machine-readablemedium of claim 37, the method further comprising: receiving anidentification of a regulatory threshold or negotiated volume threshold;generating, by the at least one processor of the transaction routingserver, one or more pseudo-networks corresponding to one or more of theplurality of eligible payment networks, each pseudo-network comprising amodification of a network to account for a change in regulatoryexemption status or a change in preferred status; dynamicallyidentifying, by the at least one processor of the transaction routingserver, one or more breakeven transaction amounts for each eligiblepayment network, the breakeven transaction amounts defining a point atwhich two or more of the plurality of eligible payment networks have thesame expenses for a given transaction amount; and dynamically sorting,by the at least one processor of the transaction routing server, theeligible payment networks and pseudo-networks to identify a least-costnetwork.